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- Outline 
L 
。 Introduction to accessibility 
* Story of an ‘a’ 
。 Input side 


。 Output side 


Color blindness: 8% male, 0.5% female 


What is accessibility? 
SSS 


AKA a11y 
Usable by people with specific needs 
* Blind * Cognition (dyslexia, attention 
e Low vision disorder, memory, ...) 
* Deaf * Motor disability (Parkinson, ...) 
* Colorblind * Elderly 
* One-handed See Accessibility HOWTOs 


e YOU 


“Handicap” depends on the situation 
and is not necessarily permanent 6 


#5" Why making GUI accessible? 


(when textmode seems so easier to make 
accessible) 


e Alot of stuff is not available in textmode 
- e.g. real javascript support 


e Business applications 


。 Non-tech people need to get help from non- 
tech people around 


Dedicated software”? 
—_—-»»j/ /ÉkiiiÉ(A(A(i( (A’$IT]H[-][H[[F 
* e.g. edbrowse, a blind-oriented editor/browser 

* Generally a bad idea! 
- Oriented to just one disability 
- Lack of manpower 


* e.g. Web browser 
- javascript/flash/table/CSS support? 
e e.g. An office suite 
- MSOffice/OpenOffice compatibility? 
- Disabled & non-disabled working together 
* Better use the same software 


> Better make existing applications accessible " 


- Design principles 
Eee 
e Same software, made accessible 
- Understand each other, get help, etc. 
e Synchronized work 
— Just alternate input/output 
- Being able to work together 
* Pervasive 


- Shouldn't have to ask for software installation / 
configuration 


Status in a few words 
EEE] ::{G1t_y_ 
e Text mode is generally quite well accessible 
- But not so well suited to beginners 
e Gnome quite accessible 


- Gnome 3 was however almost a restart-from- 
scratch 


e We're late compared to the Windows world 
- We started less than a dozen years ago 
- They started a couple of decades ago 
e We're Stone Age compared to the Apple world 
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- Really good and integrated support 


Story of an ‘a’ 


Input 


KeyPress(38) 


m ya 
input—evdev 
X server keycode 
event(KEY_A) i.e. 
physical 
position 


scancode Oxle 


keyboard 


Input 


input_signal(a) 


XKB handles turning 
into keysym, I.e. 
keyboard cap 


Widget eventually 
XKB | 
has some behavior, 
e.g. append to text 
Xelen toolkit main loop 


KeyPress(38) i 


toolkit input 


KeySym(XK a) 


Sotto 4 Output 


text rendering 


| e.g. pango | 
X client 上 上 Pixmap very early! 


video driver 


video card 
screen 


Not necessarily a 
screen, actually... 
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Accessibility in input 


Versatility FTW! 
E SSS 
Some people can only use 
e A keyboard 
- Keyboard shortcuts, move mouse with it, ... 
* A joystick 
- Use it as a mouse 
e A mouse or a button 
- Use it on a virtual keyboard 


- Keyboard layouts 
Eee 
e One-hand? 
- Would need to move the hand a lot 
- Toggle to "mirror" the keyboard layout 
e| = | al stelle] sis] sie} it =| "| 
| ARBAB 
Control |: fel «| afu] c|(rlo|s| ali Return | 
see [?|i[wIn[e]v|e]x[z] 7 [ge] sw] 
ea CIC EEE 
- Not sure where to implement it, 
and layout details 23 


AccessxX 


Basically fine-tuning 

e StickyKeys: modifiers get sticky 

e MouseKeys: turn keyboard into mouse 

e SlowKeys: require key pressed for some time 
。 RepeatKeys: slow down repeat 

* ToggleKeys: audio alert for toggles 


。 BounceKeys: delay between strokes 
- E.g. Parkinson 
Implemented in XKB in X server & X client á 


- Virtual keyboard 
——rrr  _@_o_c 60m _@@"@dpkkkHkH—————=zmé 


apa gadd BE xvkbd (v3.3) 

"HHHHHHHHHHEEHNH ts [ESI 

ce [e|w]ejs]v]vfe]v[o[e[t[ oe] elo ofr | 

EN: [01:51:15] | pamm 

sn Da MD PA LN DN MN DD BPA PP aa sels]... 
wa Se] evef (JP DE EN o dol 


STO Virtual keyboard 
——rrTT——T, __’_ _ o  Ùota|—|{1dÎqÈq n————@@ms 


| toolkit widget 


input_signal(a) 


KeySym(XK_a) 


olien toolkit main loop 


KeyPress(38) 


38(=30+8) 


XTest injection 


event(KEY_A) 


X server 


scancode Oxle 
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keyboard 


Braille keyboards 


Some braille devices have a classical PC 
keyboard a 


input_signal(a) 
e No problem 


KeySym(XK a) 


X client toolkit main loop 


KeyPress(38) 


= EN 
input-evdev core 
X server 


event(KEY_A) 


britty 


event(KEY_A) 


scancode Oxle 


kernel 
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- Braille keyboards 
E 
Others have a braille keyboard 
e 8 keys for the 8 braille dots — 256 patterns 
。 Only a-z are world-standard, rest: 


- Depends on the language 
e ' is not the same in English and in French! 
- Depends on the country 
e fr_BE vs fr CA vs fr FR 
- Depends on usage 
e French braille revisited several times. 
* VisioBraille devices have their own table. 28 


- Braille keyboards 
"——_reoe@m—m———;iié« “« io} 
But now we have a keysym, not a keycode 
e Have to backtranslate... po 


input signal(a) 
Typing 'A' 
. i KeySym(XK_a) 
e Find case modifier 


Typi ng ' Koma. a) 


Ke Press(38) ， 


KeyPress(38) 


* Find dead or m E 1 


combining rU 
event(KEY. A) ee ROSE) _, biiy 
accent 


| KEY _A=30 
kernel 


scancode Oxle 


keyboard 


Remap hack, eww 


PC Braille keyboard 
= 
Typing braille with the PC keyboard 

eJilepspspslslelslslalz[z]i17| 

mel elelelel reel fol] ii 

. SERRE — 

Te [oo PI Tes E 

el ale] el | 


e Turn into dots 
e Then turn into text 


LLL PC Braille keyboard 
Mere XKB layout + imLcFit + Xcompose 


toolkit widget 


input signal(b) 


toolkit input 


KeySym(XK b) 


XK braille dots 12 


KeyPress(41) XK braille dot 1 
KeyPress(40) XK braille dot 2 


MK lent toolkit main loop 


KeyPress(41) 32 
KeyPress(40) 


Braille abbreviations 
HH 

。 “Grade 0° ~= integral ~= litteral 

- One cell for each character 

- 8bit charsets: a mere bijection 

Ab Ba C> “一 '.. 

- Unicode and several languages: ambiguity 

e “Grade 1/2" ~= abbreviated ~= contracted 


- Common language parts expressed with few 
cells 
e eg. "ation" is … 
- Ambiguity 


e "ation is the same as “N” 


SEI PC Braille keyboard 


[bus daemon 


toolkit widget 


input_signal(b) 

KeySym(XK_b) 

KeyPress(41) an LEM 
KeyPress(40) 


KeyPress(41) 
KeyPress(40) 


ibus-sharada-braille 


X client 
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How about wayland? 
“RH 
* Is it passing keycodes, keysyms, something 
else? 
。 Ideally should allow synthesizing all of them. 


e Opportunity to fix all of this? 


Accessibility In output 


Tinkering with the rendering 
3 
* Tweak DPI to get bigger icons & fonts & such 


e Xrandr panning support for basic zoom 
« Gamma tuning & color inversion 

e Screen mirror (!) 

e TODO: Gtk3 “perfect” magnification 


- Widget requested to render in a bigger pixmap 


But for blind people”? 
=—===—=—-;;== HE 
And a lot other accessibility possibilities 
。 Don't try to patch rendering, 


e Make applications expose their semantics 
instead 


X accessibility, Mercator 1.0 


X server 


text 


Mercator 
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X accessibility, Mercator 1.0 


X server 


pixmap 


Mercator 


pixmap 
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St og Generic methodology 


Accessibility device 


bus 
Visual Rendering 42 


St s Story of an 'a', continued 


text-changed 


signal 
toolkit widget 


text 


text-changed 
braille 


message 


speech 


X client pixmap 


X server 
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But screen reader 
also needs reading 


Le. browse the application content 


get text 


get text message 


toolkit widgets 


X client 


。 Get text 
* Get parent, children 
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Abstract representation 
__—___ ———————À3 


e Window 
- Vertical container 
e Menu bar 
- File Menu 


。 Open Menu Item 


e Horizontal container 


- Text area 
— Ok button 


Technically speaking 
NENNEN 
* Alot of applications are already technically 
accessible 
- Console 
- GTK 
- KDE-Qt4/5 ("Real Soon Now") 
- Acrobat Reader 
e Alot are not 
- KDE-Qt3 
- Xt 
- Self-drawn (e.g. xpdf) al 


- In practice 
0333333 
* Alot of technically-accessible applications 
actually aren't really usable 


- A visually-organized mess of widgets... 


First name: Foo 
Last name: Bar 
Password: baz 


- In practice 
=_————___@ee—eEemumw——reeeÌÙmTzymT;Ù) em — béj 
* Alot of technically-accessible applications 
actually aren't really usable 


- A visually-organized mess of widgets... 


First column 

- Label First Name 
- Label Last Name 
- Label Password 
Second column 

- Text Foo 

- Text Bar 

- Text baz 
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STO In practice 
=_————___@ee—eEemumw——reeeÌÙmTzymT;Ù) em — béj 
* Alot of technically-accessible applications 
actually aren't really usable 


- A visually-organized mess of widgets... 
- Label First Name for Text Foo 


- Label Last Name for Text Bar 
- Label Password for Text baz 
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- In practice 
=_————___@ee—eEemumw——reeeÌÙmTzymT;Ù) em — béj 
* Alot of technically-accessible applications 
actually aren't really usable 


- A visually-organized mess of widgets... 


First column 

- Label First Name 
- Label Last Name 
- Label Password 
Second column 

- Text Foo 

- Text Bar 

- Text baz 
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- In practice 
a 
e Alot of technically-accessible applications 
actually aren't really usable 


- Avisually-organized mess of widgets... 


First column 

- Label First Name 
- Label Last Name 
- Label Password 
Second column 

- Text Foo 

- Text Bar 

- Text baz 


> Screen reader “Script” for each application 
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e” 
Don't try to make applications accessible, 


just make accessible applications 


Quite often just a matter of 
common sense from the start 


Not a reason for not fixing 
your existing apps of course, 
it will just be a bit harder :) 


Graphical applications 
“et 
* Design your application without gui in mind first 
- Logical order, just like CSS © 
e Use standard widgets 
- e.g. labeled text fields 


- Avoid homemade widgets, or else implement atk 
yourself for them 


- Always provide alternative textual content for 
visual content 


e Keep it simple! 


- Not only to make screen reading easier, but to » 
make life easier for all users too! 


Some pitfalls and advices 


(from the accessibility howtos) 
e Shouldn't have to use the mouse for anything 
* Care of contrasts, configurable colors 


e Avoid timing-based actions, or make them 
configurable 


e No 2D organization, logical organization 
* Keep it simple and obvious 


Accerciser 


Check that 
the tree of 
widgets looks 
sane and IS 
complete 


Text, notably 


File View Help 


Name Role children 
v gnome-terminal application 1 


v O Isruser@lifebook: ~ frame 
ví] filler 
> [Eile menu bar 
b [3 page tab list 


v [4 gedit application 
v Unsaved Document 1 frame 


filler 


menu bar 


IPython console | API browser 


In [14]: acc.parent 

Out[14]: <CORBA.Object 'IDL:Accessibility/Accessible:1.0' at Ox87cd2e0> 
In [15]: [child.getLocalizedRoleName() for child in acc] 

Out[15]: ['menu', 'menu', 'menu', 'menu', 'menu', 'menu', 'menu'] 
In [16]: acc.getLocalizedRoleName() 

Out[16]: 'menu bar' 

In [17]: acc.getR 

acc.getRelationSet 

acc.getRole 

acc.getRoleName 

In [17]: acc.getR 


Path: 0 0 0 


Documentations 
a —_— 5 E? io)È®OÙQ( II 
* Accessibility HOWTOs 
- Quite old, but still very useful advices 
e Gnome Accessibility devel guide 


- For GTK applications 


Conclusion 
a -s&sscssog (:;;y/ iii$éi€è ig]r;RGG “i [L2 

e Accessibility has very diverse X needs 
- Plug at various levels 
- Needs various tweaks 
> We need no regression there! 

。 Accessibility needs the semantics, 

not just the rendering 


— Separate form from content 


